Network Working Group IAB Advisory Committee 
Request for Comments: 3716 IETF 
Category: Informational March 2004 


The IETF in the Large: Administration and Execution 
Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2004). All Rights Reserved. 
Abstract 


In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB 
Advisory Committee (AdvComm), with a mandate to review the existing 
IETF administrative structure and relationships (RFC Editor, IETF 
Secretariat, IANA) and to propose changes to the IETF management 
process or structure to improve the overall functioning of the IETF. 
The AdvComm mandate did not include the standards process itself. 


This memo documents the AdvComm’s findings and proposals. 
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1. Introduction 


In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB 
Advisory Committee (AdvComm), with a mandate to review the existing 
IETF administrative structure and relationships (RFC Editor, IETF 
Secretariat, IANA) and to propose changes to the IETF management 
process or structure to improve the overall functioning of the IETF. 
This purpose was defined in the IAB Advisory Committee (AdvComm) 
charter, copied in Appendix A. The AdvComm mandate did not include 
the standards process itself. 
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The tangible output of this committee is a set of observations and 
recommendations for the IETF’s executive structure - how the IETF 
might be organizationally (re)structured so that it can effectively 
and efficiently carry out its administrative activities. Asa 
necessary preamble to that, a description of the current issues and 
future requirements is presented. The output does not represent any 
decision-making or implementation -- see Section 1.3 for a discussion 
of follow-on steps. 


1.1. Overview of the AdvComm Work Process and Output 
The AdvComm was formed in September 2003, and carried out its work 
over the course of the following 2 months, prior to the IETF58 in 


November of 2003. 


The AdvComm’s membership included many of the individuals who are, or 
have been, volunteered to manage the IETF’s inter-organization 


administrative relationships in recent years. The first phase of the 
committee’s work, therefore, included sharing and discussing the body 
of tacit knowledge about those relationships. This included the 


input from the current IETF and IAB Chairs in Appendix B, and yielded 
the IETF organizational structure information in Section 2.1. 


The committee also sought input from the other end of the key 
existing administrative relationships (RFC Editor, Secretariat, and 
TANA). The output of those efforts is included in Appendix C, 
Appendix D, and Appendix E, and these were also used as the basis for 
the observations in Section 2. 


From these inputs, the committee drew together a list of requirements 
for successful future IETF administration, documented in Section 3. 


Finally, the committee put together some advice for how the IETF 
might consider reorganizing its administrative structure to meet 
those requirements moving forward -- Section 4. 


1.2. Scope 


The AdvComm endeavored to stay focused on the IETF executive 
structure -- the collection of organizations that work together to 
bring the IETF’s work to reality. However, by virtue of the very 
fact that those relationships exist to get the work done, it was 
important to bear in mind the work being done in the IETF PROBLEM 
working group and IESG proposals for change, even as the committee 
endeavored not to infringe on the scope of those efforts. The 
objective is that these observations and proposals should be relevant 
for today’s IETF and any near-term evolutions that are deemed 
appropriate. 
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1.3. Next Steps 


This documents the state of the AdvComm’s thinking at the end of a 
two month process, and brings the currently-chartered work of the 
AdvComm to a close. 


Next steps include review of this material by the community, and 
specific proposals for action that will be put forward by the IAB and 
IETF Chairs. 


2. Observations 
2.1. Current IETF Support Structure 
2.1.1. What the Term IETF Includes in this Document 


RFC 3233 ([1]) provides a definition of the IETF, in terms of its 
work and its participation. 


This document discusses the collection of organizations that work 
together to support the effort described in RFC 3233. In this 
document, the term "IETF" explicitly includes the IESG, WGs, IAB, 
IRTF, and RGs. This inclusive sense accords with considerable common 
usage of the term "IETF". Formally, the IAB and IRTF are chartered 
independently of the IETF. However, rather than coming up with a new 
term to encompass "the IETF and all its friends", the common usage is 
followed here. 


2.1.2. Functions 


The work of the IETF is supported by a specific set of functions. It 
is useful to distinguish between the functions and the organizations 
which provide those services, as outlined in the table below. In 
some cases a Single organization provides multiple services, but the 
functions are logically distinct. 
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Function Known as Organization 
(within the IETF) 

IESG Support Secretariat Foretec/CNRI 
IAB Support ISOC/Secretariat ISOC, Foretec/CNRI 
WG Support Secretariat Foretec/CNRI 
Community Support Secretariat Foretec/CNRI 
IETF Meetings Secretariat Foretec/CNRI 
RFC Publication RFC Editor USC/ISI 
Standards Status Record RFC Editor USC/ISI 
Parameter Reg. IANA ICANN 


Legal, insurance, etc. (largely invisible) 


Table 1. IETF functions, labels 


Provided by ISOC 


and organizations 


In more detail, the functions can be broken down as follows: 


IESG Support 


Telechats 

Communications 

IETF document tracking 

Working document management (mailing list, 


IAB support 

Telechats 

Communications 

Working document management (mailing list, 
WG support 

Charters 


Milestone tracking 
Workspace (website, mailing list) 


website, repository) 


website, repository) 


Working document archive (mailing list archives, document 


repository) 
Community Support 


Website 

IETF mailing list 
Announcements 

I-D repository 
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RFC Publication 


Website 

RFC editorial 

Document publication 

RFC repository management 
Official standards status record 


IETF Meetings 


Planning 
Meeting Proceedings 


Protocol parameter registration 


Creation of registries 
Assignment of protocol parameters 
Management of accessible registry repository 


Legal, insurance, etc. 


Legal support 
Liability insurance for IAB, IESG, WG chairs, etc. 
Miscellaneous 


2.1.3. Support 


A presentation of the scope and depth of support that created the 
IETF and has allowed it to continue to contribute would require a 
discussion of history that is rich, vibrant, and completely beyond 
the scope of this document. However, a very brief introduction to 
some of the current pillars is needed to understand where the IETF is 
today. 


ISOC: Since 1992, ISOC has been the organizational home of the 
IETF. This activity is part of its more general mission of 
serving as the international organization for global coordination 
and cooperation on the Internet, promoting and maintaining a broad 
spectrum of activities focused on the Internet’s development, 
availability, and associated technologies. 


Foretec/CNRI: The Corporation for National Research Initiatives 
(CNRI) was founded in 1986, and since 1987, CNRI has served the 
community by providing IETF Secretariat services. Until the early 
1990s, CNRI provided legal assistance to the IETF and the IETF 
Secretariat. After ISOC was founded, ISOC assumed overall legal 
responsibility for the substantive workings of the IETF including 
the efforts of the IETF chair, the IESG, the IAB, the area 
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directors and the working group chairs. CNRI assumed operational 
responsibility for the substantive workings of the IETF 
Secretariat. In 1998, in order to decrease overhead costs on the 
activities, the Secretariat was reorganized placing Secretariat 
employees including the IETF Executive Director in a CNRI for- 
profit subsidiary (Foretec Seminars, Inc.). Foretec was founded 
in 1997, in anticipation of the Secretariat becoming self- 
supporting. CNRI and its subsidiary have continued to improve the 
operation of the Secretariat, as appropriate, and maintain a 
trained staff. 


USC/ISI: The role of the RFC Editor, and USC/ISI, is detailed in 
RFC 2555. The RFC document series is a set of technical and 
organizational notes about the Internet (originally the ARPANET), 
beginning in 1969. For 30 years, the RFC Editor was Jon Postel, a 
research scientist and manager in the Networking Division of the 
USC Information Sciences Institute (ISI), with the function 
gradually evolving into a team headed by him. The RFC Editor 
activity is currently organized as a project within ISI, using the 
ISI infrastructure, and supported by a contract with ISOC. The 
RFC Editor is the publisher of RFCs and is responsible for the 
final editorial review of the documents, as well as the 
maintenance of the online repository and index of those documents. 


ICANN: The Internet Corporation for Assigned Names and Numbers 
(ICANN) is the non-profit corporation that was formed in 1998 to 
assume responsibility for the IP address space allocation, 
protocol parameter assignment, domain name system management, and 
root server system management functions previously performed under 
U.S. Government contract by IANA (at ISI) and other entities. 


The support picture (who does what) can be described as follows: 
Secretariat at Foretec/CNRI 

IESG Support 

TAB Support (working document management) 

WG Support 

Community Support 

IETF meetings 
RFC Editor at USC/ISI 

[Supported by ISOC, based on a contract between USC/ISI and ISOC] 


RFC publication Maintenance of standards status record 
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IANA/ ICANN 
[Relationship defined by Memorandum of Understanding: 
Protocol parameter registry 
ISOC 


IAB Support (Telechats) 

Funds RFC Editor 

Misc IAB/IESG expenses 

Provides insurance for IAB, IESG, WG chairs, etc. 


The available resources to support these activities are: 


Meeting fees -- through Foretec 


ISOC members’ contributions for standards 
ICANN for IANA 


Volunteers/their employers (where applicable): 


Deki 


IETF participants 
WG chairs 
Document editors 
IETF NomCom 

IESG 

TAB 

IAB ExecDir 


Observed Stress Points 


The AdvComm noted several properties of the current IETF 


March 2004 


RFC 2860] 


organizational environment that cause stress in the system. These 
have been noted both from the point of view of the IETF leadership as 


well as that of organizations supporting the IETF. 


1. Stress Points Observed by IETF Leadership 


The current IETF funding and operational structure is dependent on 
IETF meeting attendance. Therefore, the most obvious stressor that 
has emerged within the last two years is the decline in that 
attendance. This trend, which has continued unabated, has resulted 
in a decline in IETF revenue (detailed in the IETF chair presentation 
at IETF 56 [2]), even as the requirements of the IETF operation are 


remaining constant or increasing. 


IAB Advisory Committee Informational 


[Page 8] 


RFC 3716 The IETF: Administration and Execution March 2004 


The result has been a budget deficit for operations which began in 
2002, and is forecasted to continue until at least 2004, even after a 
substantial increase in meeting fees. The continuing deficits have 
depleted working capital, making the IETF less robust against 
potential future budgetary disappointments. 


The financial stress is real, but the IETF leadership has noted 
several other stressors that are impediments to finding and 
implementing solutions to the fiscal issues. Some obvious solutions 
are not implementable in the current IETF structure. 


The rest of the stressors listed in this section should be understood 
as issues for which relief is necessary, particularly in the light of 
needing to properly address and implement solutions to the financial 
stress. 


The current documentation of IETF processes and structure is, in 
places, vague about the distribution of responsibility for management 
and oversight of the IETF administrative relationships. This makes 
it opaque to the IETF community, and sometimes leaves the leadership 
in a poor position to manage effectively. 


Additionally, the informality of the relationships with some of the 
organizations that are carrying out key IETF functions compounds the 
problem of determining who has responsibility, and how IETF community 
consensus and desires are reflected in the activity. 


As a separate issue, important IETF institutional memory is recorded 
nowhere other than peoples’ minds in many cases -- which requires 
significant transmission of oral history for IETF leadership 
transition to be effective. 


Apart from the institutional memory, other important IETF 
institutional records are spread across various organizations, and 
searching for the set of relevant documentation (especially when this 
is necessary long after the recording) can be challenging. 


Another stressor relates to the need to scale support processes in 
terms of reducing latency for mechanical processes. That is, a 
decrease in the amount of manual labor required for the simpler tasks 
between the organizations, would make more resources available to 
focus on the special cases. Lack of automation in the basic request 
services has been known to cause undue delay or failure in processing 
simple, routine tasks. However, automation also requires resources 
and significant management in order to make sure it fulfills the 
community’s requirements. 
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2.2.2. Stress Points Observed by Organizations Supporting the IETF 


Supporting organizations report difficulties in determining 
authoritative channels for directions -- either too many inputs, or 
no clear authority for resolution of change requests. 


In the absence of written agreements, supporting organizations may 
not be clear from whom to take direction. Even where agreements 
exist, the authority to provide direction may not be clear. The 
genesis of both problems is that the IETF relies on external bodies 
for support, but does not have sufficiently clear external 
relationships to allow it to provide input as to its requirements or 
direction on what services it desires. 


2.3. A Final Observation 


This section attempts to capture a snapshot of the current state of 
the IETF organization, without undue fixation on the causes for 
arriving at the current state. However, it seems clear from the 
observations that the current state does not provide an adequate 
structure from which to reach into the future: some changes are 
needed within the IETF administrative and executive structure. 


3. Stand Facing the Future: Requirements for a Successful IETF 
Administration 


This section follows the set of observations with a set of 
requirements for a properly-functioning IETF administrative 
structure. These requirements are offered as the AdvComm’s 
description of what the IETF needs, without addressing immediately 
the degree to which they are available with the current environment. 
That is, these are "requirements", not "requirements for change". 


3.1. Resource Management 
3.1.1. Uniform Budgetary Responsibility 


The IETF has operated in times of financial wealth and times of 
economic cutbacks in the industry. It is reasonable to expect that 
the future holds similarly variable trends. Therefore, it is 
important that the IETF organization has the ability to make the 
decisions to match its needs at a given point in time, i.e., 
budgetary autonomy. At this particular moment, there are hard 
choices to make, and the AdvComm believes that it is the IETF 
leadership, with the advice and consent of the IETF community, that 
needs to make them. 
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3.1.2. Revenue Source Equivalence 


The IETF is currently supported by money from multiple sources, 
including meeting fees, donations from interested corporate and non- 
corporate entities, and donations in kind of equipment or manpower. 
The IETF needs to be able to consider all sources of income, and all 
expenses involved in running the IETF, as pieces of one budget, to be 
free to adjust all items on the occasions when the income from the 
different sources varies, and to allocate funds as reasonably 
required. 


The usual caveats apply: that donations not threaten the 
independence of the IETF, and that donations are easier when they are 
tax deductible. 


3.1.3. Clarity in Relationship with Supporting Organizations 


While the IETF needs to be able to manage its revenue streams against 
its expense expectations, it also needs to respect the needs of 
supporting organizations to manage their own affairs. That is, the 
text above does not suggest that the IETF should micro-manage the 
financial affairs of supporting organizations. 


However, the very clear requirement is for clarity in the 
distribution of rights, responsibilities, and accountability in those 
relationships. The usual mechanism for documenting such clarity is 
in contract form. Thus, the IETF needs to have clear contractual 
relationships with the organizations supporting basic services, 
including meeting organization, secretarial services, IT services, 
etc. 


3.1.4. Flexibility in Service Provisioning 


The IETF needs to be able to raise money for, and fund the 


development of, additional services as appropriate. This includes 
the development of tools for participants, repository management, 
etc. 


3.1.5. Administrative Efficiency 


The IETF’s needs should be met with the minimum of overhead. This 
implies that there needs to be the possibility of combining work 
efforts where appropriate, and generally avoiding duplication of 
effort. 
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3.2. Stewardship 


The requirements described below focus primarily on the needs of the 
IETF administration on a day-to-day basis. However, responsible 
management includes stewardship for future IETF work. 


3.2.1. Accountability for Change 


The IETF needs to be responsible for changing its administrative 
structure to meet the community’s evolving needs. As such, the 
administration needs to remain uniquely accountable to the IETF 
community. 


This also means that the distribution of responsibilities must be 
clear to the IETF community, in order to permit it to comment on 
current actions or future plans, and also to allow it to take action 
when its needs are not being adequately addressed. 


An implication of this is that responsibility for financial 
management within the IETF needs to sit with individuals who are 
accountable within the IETF organizational structure. 


3.2.2. Persistence and Accessibility of Records 


Much of the work of the IETF is focused on reaching decisions and 
declaring closure. However, responsibility does not stop with the 
declaration of completion. There are any number of reasons that 
history must be adequately documented so that future work can review 
substantive records, and not rely on oral history. 


Therefore, the IETF needs to maintain and support the archiving of 
all of its working documents in a way that continues to be 
accessible, for all current and future IETF workers. 

3.3. Working Environment 
Part of the job of administering the IETF is identifying and ensuring 
the continued support of the tools and working environment necessary 
to support the ongoing activity. 

3.3.1. Service Automation 
Wherever human judgment is not required in order to complete an 


action, services should be automated to provide the most friction- 
free path and minimal delay in completing the action. 
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More processes could be accomplished without requiring human 
judgment. Wherever possible, these processes should be identified, 
clarified, and automated. 


Note that this is not intended to imply ALL processes should be 
automated! Rather, by reducing the friction incurred in steps that 
are truly mechanical, more time and energy will be available to 
properly treat those that require individual judgment. 


3.3.2. Tools 


Whether housed in an IETF-supported location or offered by individual 
contribution, the PROBLEM WG has identified the need for more tool 
support for working groups and specification development. The IETF 
needs to be able to identify, develop and support an adequately rich, 
consistent set of tools for getting the standards work done. 


4. Advisory Committee Advice 


The Advisory Committee discussed the material and observations, 
described in this document, at great length. To the AdvComm, it 
appeared clear that some level of IETF administration organizational 
change is needed to address the stressors and meet all of the 
requirements outlined in Section 3. 


4.1. Proposed: (Single) Formalized IETF Organizational Entity 


In order to ensure an IETF structure that is capable of meeting the 
requirements outlined above, the AdvComm recommends that the IETF be 
more formally organized. This would allow the IETF to take full 
responsibility for, and management of, the resources required to 
accomplish its work (as described in Section 3.1), provide and 
maintain the necessary work environment for current work (as 
described in Section 3.3), and provide appropriate stewardship of the 
institutional information required for all aspects of current and 
future work of the organization (as described in Section 3.2). 


Some proposed models for establishing such a formalized effort are 
described in the following sections. Some of the key expectations, 
irrespective of the final implementation of formalism, are: 


o the administration of the IETF would remain accountable to the 
IETF leadership and community; the goal would be to ensure that 
lines of responsibility and accountability were clearer; 


o this formalized IETF would be responsible for managing financial 
resources (revenue and expenses) directly; 
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o this formalized IETF would be directly signatory to agreements 
with other organizations, and would therefore be able to negotiate 
and administer any appropriate contracts; 


o however implemented, this would require a small staff complement 
(e.g., one full-time person) responsible to no other organization 
than the one chartered with the IETF’s mission; 


o nevertheless, it remains a non-goal to create an organizational 
entity that exists simply for the purpose of continuing to exist. 
This should be executed with the minimum formality needed in order 
to address the identified requirements. 


4.1.1. Comments on the Necessity of this Formalization 


An important question is: what does this proposed formalization 
provide that cannot be provided by the status quo? The AdvComm 
believes that an appropriately implemented formalization of the IETF 
would permit the unification of the resource management, decision 
making and stewardship that is imperative to providing clarity and 
ensuring a viable future for the IETF. The AdvComm further believes 
that this is simply not possible to implement within the existing 
distributed and informal arrangement of responsibilities. 


Naturally, the act of forming such an organization does not 
immediately satisfy the requirements outlined in Section 3. It is 
not a silver bullet. Changing the formal structure will not, for 
example, change the financial status of the IETF. However, the 
AdvComm believes it would provide the necessary basis from which the 
required decisions could be made and acted upon. 


In short, the AdvComm believes that we first have to place the 
responsibility for defining the IETF’s administrative environment 
with specific people who are accountable to the IETF community. Then 
these people can take the detailed decisions that will change the 
TETF’s administrative environment to fulfill its requirements. 


4.2. Possible Structures 


Section 4.1 was deliberately vague on the nature of the formal 
organizational entity that might provide the proper environment, 
focusing instead on the key components of any implementation of such 
a formalization, and how the formalization activity would address the 
requirements laid out in Section 3. 
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Having thus determined that formalization of the IETF is seen as a 
necessary step, the basic framework for 3 potential implementations 
of it are described below. Note that these are not complete 
proposals, nor is enough detail available to recommend a particular 
path. The IETF leadership might select one to explore in greater 
detail, to formulate an action proposal with sufficient detail to 
make a decision to act. 


4.2.1. ISOC 


The IETF is organized as an activity of the Internet Society. One 
potential path for increased formalism of the IETF’s administration 
would be to further define that relationship. This model anticipates 
dedication of ISOC personnel to form the "small staff complement", 
and would make ISOC responsible for all of the IETF’s financial 
resources and expenses. 


This approach should be relatively straightforward to implement, 
given ISOC’s existing legal relationship with the IETF activity, and 
its status as signatory for IETF-related contracts (e.g., RFC 
Editor). 


This proposal is consistent with the goal of minimizing the amount of 
formalization needed to meet the requirements of the IETF. 


However, the general mission of ISOC is broader than the 
standardization activity of the IETF, and the ISOC Board of Trustees 
must stay focused on apportioning resources to meet that broader 
mission. Would this approach allow the clear lines of responsibility 
that are called for in Section 3? 


4.2.2. ISOC Subsidiary 


A modification of the proposal of housing the IETF central body 
within ISOC is to create a legal not-for-profit subsidiary of ISOC, 
with a mandate that is specifically focused on the IETF’s mission. 
This subsidiary would become the legal entity responsible for 
managing the IETF’s resources and expenses, and would become 
signatory to any other legal instruments on the IETF’s behalf. 


As a distinct legal entity in its own right, the subsidiary would be 
independently responsible for achieving its mission. That level of 
independence addresses the concern raised against the notion of 
further formalizing the IETF within ISOC directly -- that the IETF 
mission might be disrupted by the organization’s need to tend to 
other aspects of ISOC’s broader mission. The role of the IETF 
community, and the ISOC parent, in defining and supporting that 
mission would be spelled out in the creation of the legal body. 
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The IETF might additionally consider what the most appropriate 
governance model would be for this approach. If it is desirable to 
remove some of the administrative burden from the IESG and IAB, such 
a subsidiary might have its own Board of Trustees, composed of 
members appointed by IETF and ISOC. Such a Board would be 
responsible for reviewing activities and ensuring that the 
organization’s efforts were adequately in line with its mission, its 
finances were in order, and so on. The subsidiary would report to 
its Board of Trustees. Other governance models are certainly 
possible, and a Board of Trustees is not a requirement for this 
approach. 


At the same time, as a subsidiary organization, the expectation is 
that the relationship with ISOC would remain a close one: the 
subsidiary would benefit from ISOC’s existing infrastructure and 
support (a conservative approach to adding formalism and structural 
overhead to the IETF activity), while the relationship would continue 
to provide a channel for the IETF to support ISOC in achieving that 
broader mission, with continued contribution of technical expertise 
and support of activities. 


This approach would require more work to create than simply housing 
the work at ISOC. The subsidiary would have to be created and 
rights/responsibilities adjusted between it and ISOC in order to 
ensure that both have the necessary resources and frameworks to carry 
out their missions. 


4.2.3. Completely Autonomous Organizational Entity 


To complete the picture, a third option has to be considered. Instead 
of creating a subsidiary of ISOC as a separate legal entity, an 
entirely new legal entity, "IETF, Inc.", or "IETF, LLC", could be 
created for the sole purpose of managing IETF administrative 
activities. 


This would offer the IETF complete autonomy with all the attendant 
rights and responsibilities. In particular, an independent IETF 
would at a minimum, need to operate much like a startup for the first 
few years of its existence, with all the related financing and growth 
issues, and survival risks. Given all the organizational change 
taking place within the IETF during the same period, the AdvComm 
believes that the financial and political risks of such an approach 
should not be under-estimated. 


For example, it would be necessary for the IETF to obtain initial 
working capital sufficient to handle the commitments for the first 
few meetings. While it would be conceivable to raise working capital 
from advance meeting fees, such a financing plan would not leave much 
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margin for error; were one or more of the initial meetings to run in 
the red, the survival of a fledgling IETF could be in jeopardy. Given 
the economic environment, it probably should not be assumed that 
working capital could be raised purely from corporate donations, 
especially during an initial period in which staff required to 
solicit and manage donations would not be available. 


Additionally, the impact that such a move would have on ISOC’s 
ability to carry out its mission and the IETF’s standing with 
governmental organizations needs to be considered. 

4.3. Who Can Decide 
The AdvComm believes that the IETF leadership, acting with the advice 
and consent of the IETF community and ISOC, have the ability and the 
responsibility to act on the recommendation to formalize the IETF. 


5. Security Considerations 


This document does not describe any technical protocols and has no 
implications for network security. 
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Appendix A. IAB Advisory Committee Charter 


Date: Tue, 02 Sep 2003 16:34:58 -0400 

From: Leslie Daigle 

Subject: Formation of IAB Advisory Committee 
To: IETF-Announce: ; 


I would like to announce the formation of an IAB advisory 
committee, as described below. 


Thanks, 
Leslie, 
for the IAB. 


IAB Advisory Committee on IETF Administration Relationships 


The purpose of the committee is to review the existing 

IETF administration relationships (RFC Editor, IETF Secretariat, 
etc.) and propose IETF management process or structural changes 

that would improve the overall functioning of the 

IETF. Any such proposal will be subject to review and 

acceptance by the IAB and IETF plenary. Note that the scope of the 
advisory committee does NOT include proposed changes to the standards 
development processes (e.g., WG organization, IESG management of 
documents or working groups, etc.). 


The committee is chaired by the IAB Chair, Leslie Daigle, and 
consists of: 


Bernard Aboba 

Harald Alvestrand (IETF Chair) 

Lynn St.Amour (ISOC President) 

Fred Baker (Chair, ISOC Board of Trustees) 

Brian Carpenter 

Steve Crocker 

Leslie Daigle (IAB Chair, chair of the committee) 
Russ Housley 

John Klensin 


C000 0000 0 


Additional input is welcome. The committee will also make a 
particular effort to seek out further input as needed. -- 
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Appendix B. Input from the Current IETF and IAB Chairs 


Input contributed by Harald Alvestrand (IETF Chair) and Leslie Daigle 
(IAB Chair). 


Looking at the administrative overview of the IETF activity, there 
are a number of things that work well: 


o support organizations are committed to the work of the IETF; 


o the volunteers of the IETF WGs can (mostly) concentrate on their 
engineering work, not economics; 


o money has (so far) been sufficient to cover the costs. 
However, there are also a number of challenges: 


o lack of persistent records of the whole organization’s efforts -- 
of working documents, meeting materials, communications. Also, 


* lack of organization of records -- even when data is stored, it 
can be hard or impossible to access when no longer current 
(e.g., it may reside on some former WG chair’s hard drive) 


* history records are kept spottily (lists of wg chairs and old 
versions of charters, to mention some); 


o few safeguards against the "hit by a bus" problem -- much 
information about relationships is not documented, and must be 
transferred as oral tradition. This means that significant 
overlap is needed when personnel changes; 


o IETF leadership responsibilities are not clearly identified -- 
typically handled by IETF and IAB Chairs, with some advice and 
consent from IESG and IAB, but that makes it possible to challenge 
every change decision; 


o contracts do not clearly identify responsibility for executive 
direction. Some contractual relationships are not documented, or 
are not visible to the IETF leadership; 


o variable, and often unclear, documentation of responsibilities 
between IETF leadership and other organizations. This makes it 
hard to determine how and where to discuss and effect improvements 
for the IETF that affect one or more support organization’s 
activity; 
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unclear budgeting responsibilities -- the IETF leadership has to 
make decisions that will impact the revenues and costs of the 
supporting organizations, but the supporting organizations wear 
the direct effects of revenue and cost control. Information about 
the financial impact of decisions are not available to IETF 
leadership; 


partitioned finances -- it’s not possible for the IETF to make 
changes that would affect the balance of revenue and costs across 
the revenue sources/expense commitments. For example, raising 
meeting fees wouldn’t pay for more RFC Editor resources; more 
support from ISOC doesn’t address any needs for IETF working group 
support functions; 


the lack of clarity and the partitioning make it very hard for the 
IETF leadership, and the community as a whole, to determine points 
of accountability and implement changes for a healthy future. 


Appendix C. Consultation with ISI: RFC Editor 


Note: "RFC2223bis" in the text below refers to RFC 2223bis [4], a 
work in progress to update RFC 2223 [3]. 


+ + F HF * 


Responses to Questions from IAB Advisory Committee 
for the RFC Editor 


October 6, 2003 


(1) Your description of the function you are performing. Is 
that function, and its relationship to the IETF, adequately 
described in RFC 2223bis, or is additional description 
required? If the latter, what would you suggest? 


ANSWER: 


A comprehensive summary of current RFC Editor functions is attached 
below. Note that this list has no direct relation to RFC 2223bis, 
which contains instructions to RFC authors. 


+ + F HF o 


(2) What staff is being used to perform these functions and 
what are their particular skills for doing so (either 
individually or in the aggregate) ? 


TAB Advisory Committee Informational [Page 21] 


RFC 3716 The IETF: Administration and Execution March 2004 


ANSWER: 


For 30 years, the RFC Editor was Jon Postel, a research scientist and 
manager in the Networking Division of the USC Information Sciences 
Institute (ISI). It is currently organized as a project within ISI, 
using the ISI infrastructure. The following ISI staff members 
comprise the RFC Editor project: 


Joyce Reynolds 100% 
Bob Braden 10% 
Aaron Falk 10% 
Sandy Ginoza 100% 
Project Assistant 100% 


Graduate Research Asst. 50% 


Braden and Reynolds jointly manage the RFC Editor project, with 
oversight of personnel and budgets. 


Joyce Reynolds has been contributing her editorial and management 
skills to the Internet since 1979. She performed the IANA functions 
under Jon Postel’s direction from 1983 until Postel’s death in 
October 1998. She continued to perform the IANA protocol parameter 
tasks on loan from ISI to ICANN, from 1998 to 2001. She was IANA 
liaison to the IESG from 1998 to 2001, transitioning the role to 
Michelle Cotton in the 2001. 


Reynolds performed the RFC Editor functions under Jon Postel’s 


direction from 1987 until 1998. Reynolds has been a member of the 
IETF since 1988, and she served as User Services Area Director on the 
IESG for 10 years. Reynolds now serves a liaison to the IAB and 


IESG. She handles the final proofing and quality control on RFCs 
prior to publication. 


Bob Braden has made many contributions to the Internet protocol 
technology and community. He helped design TCP/IP during the 
original research period beginning in 1978, and he has devoted his 
professional career since 1978 to the Internet. He served for 13 
years on the original IAB and as its Executive Director for about 5 
years. Since 1998 Braden has been co-leader of the RFC Editor 
project. He is the principal reviewer of individual submissions. He 
also works on technical issues related to the RFC Editor project. 


Aaron Falk is a significant player in the IETF as a Working Group 
chair, in the areas of transport protocols and satellite technology. 
On the RFC Editor team, he assists with policy questions and handles 
technical development, overseeing the work of the grad student 
programmer. 
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Sandy Ginoza is the principal technical editor. She is generally 
responsible for managing the RFC Editor queue and much of the day- 
to-day interface with the IESG and authors. Ginoza sends and 
receives a LOT of email, and she plays a central role in the 
operation. 


Two part-time Project Assistants, Mieke Van de Kamp and Alison De La 
Cruz, do editing, mark-up, and initial proofing of individual RFCs. 
Our goal is to have three pairs of eyes read every RFC word-for-word, 
and in most instances we are able to do so. 


A half-time USC Graduate Research Assistant provides programming 
support by developing, extending, and maintaining RFC Editor scripts 
and tools. 


(3) What criteria do you use to determine whether you are being 
successful, and how successful? Using those criteria, how 
successful are you and what could be done, especially from the 
IETF side, to improve that evaluation? 


ANSWER: 


We can begin with a historical perspective on this question. When 
Jon Postel unexpectedly passed away 5 years ago, Reynolds and Braden 
took on the challenge of carrying on Postel’s RFC Editor function. 
The publication stream continued, with a modest increase in quantity 
and, we believe, no loss of quality. Furthermore, the transition was 
largely invisible to the IETF. In addition, the new RFC Editor 
project has significantly defined and clarified the publication 
process, improved the web site, added tools to improve productivity 
and quality, and adapted the procedures to changing realities. We 
are proud of these achievements. 


The three primary axes for measuring RFC Editor success are (1) 
quantity, (2) quality, and (3) accessibility. 


1. Quantity 
Roughly, quantitative success means the ability to keep up with 
the submission rate. Since the submission rate tends to be 
bursty, to avoid long delays we need an average capacity somewhat 


in excess of the average. 


RFC publication is necessarily a heavily labor-intensive process. 
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Our goal is generally to complete the publication process in less 
than 4 weeks, exclusive of external factors beyond our control -- 
normative dependence upon other documents, delays by authors or 
the IESG, IANA delays, etc. 


2. Quality 


Publication quality is harder to measure, but "we know it when we 
see it." Considering quality as the absence of faults, by noting 
faults we can observe lack of quality. 


One measure of faults is the number of errata that appear after 
publication. In addition, there may be faults apparent to a 
reader, such as a meaningless title, confusing organization, 
useless Abstract, inadequate introduction, confusing formatting, 
bad sentences, or bad grammar. There are of course limits to our 
ability to repair bad writing; ultimately, quality depends upon 
the authors as well as the editing process. 


The only way to maintain quality is to continually monitor our 
work internally, to track external complaints, and to adjust our 
practice to correct frequent faults. Specific faults have 
sometimes led us to create new tools for checking consistency, to 
avoid clerical errors. Sometimes they have led to new user 
guidelines (e.g., on abbreviations or on Abstract sections.) 


3. Accessibility 


An important part of the RFC Editor function is to provide a 


database for locating relevant RFCs. This is actually a very hard 
problem, because there is often a complex semantic web among RFCs 
on a particular topic. We have made great improvements in our 


search engine and web site, but there is undoubtedly a need for 
more progress in this area. The challenge is to provide better 
guideposts to users without creating a significant additional 
manpower requirement. 


We make heavy use of our own search and access tools, and this 
gives us feedback on their success and sometimes suggests 
improvements. 


Finally, we offer some specific suggestions to answer the question, 


"What can the IETF do to improve the RFC Editor’s evaluation" (i.e., 
our service to the community)? 
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1. Give us better documents to publish. Many are well written and 
organized, but some are bad and a few are very bad and need a 
great deal of work to create acceptable publications. Better 
input documents will improve both our quantity and our quality. 


The IESG has been making a large effort to improve the quality of 
Internet Drafts before they become RFCs, and we are very grateful 
for this. 


One issue of particular concern is the increasing number of RFCs 
authored by non-English speakers. These can consume much extra 
editorial effort. We don’t know any solution to this problem, but 
we know that the IESG is aware of it and working with them to 
provide editorial assistance when necessary within working groups. 


2. Prepare a series of RFCs containing "road maps" that describe the 
semantic web of RFCs in a particular area. Although these would 
rapidly become out-dated in detail, they would still provide very 
important guides to RFC readers. 


The RFC Editor is as self-critical as any organization could be, but 
we believe there is no objective basis for claiming that we are not 
doing a good job for the Internet. We continually strive to do a 
better job. 


(4) How would you characterize the quality of your relationship 
with the IETF and its leadership? Is there mutual trust anda 
sense of working together on issues, or do you and your 
colleagues sometimes see the relationship as adversarial? 


+ + F + F F 


ANSWER: 


The RFC Editor shares with much of the rest of the Internet community 
a deep desire to advance the technology and practice of the Internet. 
We consider ourselves partners with the IETF, the IESG, and the IAB 
in this endeavor. 


Although the major goals coincide, the IESG and the RFC Editor quite 
properly have somewhat different priorities. The RFC Editor’s role, 
historically and currently, is to create and maintain the RFC 
document series as a high-quality and vital channel for technical 
communication, while the IESG is concerned with managing the Internet 
engineering and standards process. This difference sometimes leads 
to honest disagreements, but we have generally worked out mutually- 
satisfactory solutions to these conflicts. 
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The word "adversarial" seems completely inappropriate, and we are 
struggling to understand what could have led to its appearance here. 


* (5) Are there specific known problems you would like us to look 
* at and understand? If so, please describe them. 


ANSWER: 


(A) 


The length of time for IESG review and recommendations on 
individual submissions has sometimes become excessive. We 
understand the load of IESG members, but we would like to ask 
their help in keeping response to a few months. 


The RFC Editor has been attempting to raise the bar on accepting 
individual submissions, to avoid wasting valuable IESG time as 
well as to maintain (or improve) the quality of the RFC series. 


We would like understanding and support of the RFC Editor’s 
statutory and historic responsibility to publish significant 
technical documents about networking that originate outside the 
IETF standards process. This publication has several important 
purposes. 


One is to bring out new technical ideas for consideration and 
discussion. We believe that the future success of the Internet 
demands an infusion of new ideas (or old ideas revitalized), and 
that the publication of such ideas as RFCs is important. 


Another purpose is to build a shared literature of mature 
technical discussion, to help avoid the periodic re-discussions 
that take place on our mailing lists. 


Finally, the RFC series provides a historic repository for 
important ideas. We have come across a number of examples of 
important suggestions and partial technology developments that 
have been lost, or hard to locate, because they were not 
published as RFCs. The community spends too much of our time 
re-inventing many, many wheels. 


Our ultimate goal is to publish more high-quality submissions, so 
we can raise the bar for publication. 


Independent submission publications represent only a minor 
fraction of the RFC production. For example, so far in calendar 
2003 we have published 178 RFCs, including 14 independent 
submissions. If all the drafts that we think deserve to be 
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preserved as RFCs were to be published, this fraction would grow, 
but we would not expect it to grow beyond 25% of the total number 
of published RFCs. 


(C) We would like to work with the IAB/IESG in re-examining the issue 


of normative references. We believe that the current definition 
of normative is ambiguous and unclear, and that as a result some 
publications may be unnecessarily held up for normative 
references where these are unnecessary. 


(D) We would like to cooperate in an investigation of the issues in 


extending the character set beyond US-ASCII, .e.g., to UTF-8. A 
major issue is whether there is a set of preparation, display, 
and searching tools for both the RFC Editor and the RFC 
consumers. These tools need to be ubiquitously available and 
mature enough. 


The RFC Editor is looking for input on how we can best continue to 
serve the community. We are grateful for the suggestions we have 
received, and we have adopted as many of them as feasible; the result 
has been quite a long list of incremental improvements in our service 
over the past 5 years. 


+ + + + F + F F HF F 


(6) How do you see the costs of your function evolving? If 
things become more costly over time, what are the main 
determiners of cost (e.g., general inflation, general IETF 
growth, increase in the number of particular functions you are 
carried out to perform,...). Are you doing some things that 
IETF (IESG or otherwise) request that you do not consider 
cost-effective and, if so, what are they? 


ANSWER: 


The major cost factor is the number of documents submitted and 
published. This has grown relatively slowly over time. It appears 
to us that the IETF process has (perhaps fortunately) been the 
bottleneck that has kept the rate of RFC production from growing 
exponentially. We do not expect that to change dramatically. 


In more detail, the cost factors are: 


(a) Inflation (on salaries) 


This shows a small and predictable annual increase. 
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(b) The number of RFCs published. 


This is the primary cost factor. The bulk of the editorial 
and coordinating functions are directly attributable to 
specific documents. At present, we estimate that this cost 
category represents 70% of our personnel time, and 63% of our 
cost. 


(c) Tasks not directly related to specific RFCs. 


This includes many functions: management (budget and personnel 
as well as policy and procedure development), IETF liaison, 
reviews of independent submissions, development and 
maintenance of web pages, scripts, and tools, the RFC Online 
project, maintaining the Errata web page, etc. These are 
currently estimated to require 30% of our personnel time, and 
37% of our cost. 


Minor extensions of function can be absorbed with little extra cost 
(but at a leisurely pace). We are not proposing any major functional 
extensions at this time; such extensions would have to be costed 
separately (were money available for them.) 


Disk storage and web services are provided by ISI’s support 
organization and are treated as overhead. Most of the desktop 
machines used by the project were originally bought under research 
contracts, although the RFC Editor budget includes a very small item 
for equipment upgrades. 


APPENDIX -- FUNCTIONS OF RFC EDITOR 
OVERVIEW 


The RFC Editor edits and publishes the archival series of RFC 
(originally "Request for Comment") documents. The RFCs form an 
archival series of memos about computer communication and packet 
switching networks that records the technical history of the ARPAnet 
and the Internet, beginning in 1969. The RFC Editor is funded by the 
Internet Society and operates under the general direction of the IAB 
(Internet Architecture Board). 


The RFC Editor publishes RFCs and a master index of the RFC series 
electronically on the Internet, via all common access protocols 
(currently, the Web, email, rsync, and FTP). It announces the 
existence of each new RFC via electronic mail to one or more mailing 
lists. The RFC Editor maintains a comprehensive web site with a 
variety of tools and lists to locate and access RFCs. This website 
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also contains general information about RFC editorial policies, 
publication queue status, errata, and any other information that will 
make the RFC series more accessible and more useful. 


During the RFC editing process, the RFC Editor strives for quality, 
clarity, and consistency of style and format. Editorial guidelines 
and procedures to achieve these ends are established by the RFC 
Editor in consultation with the IAB and IESG (Internet Engineering 
Steering Group). The RFC Editor periodically publishes a revision of 
these its guidelines to authors. 


The RFC Editor coordinates closely with the IESG to carry out the 
Internet standards process as documented in the latest revision of 
"The Internet Standards Process" and later amendments. The RFC 
Editor also coordinates closely with the Internet Assigned Numbers 
Authority (IANA), to ensure that the parameters used in new and 
revised protocol descriptions are properly registered. 


SPECIFIC TASKS 
I. Editing and publishing RFCs 
(1) Publication process. The RFC Editor edits and publishes RFCs in 


accordance with RFC 2026 (or replacement documents) and RFC 
2223bis. This includes the following tasks: 


(a) Performing the final editing of the documents to maintain 
consistency of style, editorial standards, and clarity. 


At minimum, the RFC Editor: 


(i) Copy-edits the documents, including the correction of 
spelling and grammar, and some checking for 
inconsistent notation. Ambiguous sentences are 
resolved with the authors. 


(ii) Enforces the formatting rules of Section 3 of RFC 
2223bis 
(iii) Ensures that sections follow guidelines and rules of 


Section 4 of RFC 2223bis. 


(iv) Verifies the consistency of references and citations, 
and verifies contents of references to RFCs and I-Ds. 


(v) Verifies that all normative dependencies have been 
satisfied. 
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(vi) Verifies that guidelines from Section 2 of RFC 2223bis 
are followed, with respect to: URLs, titles, 
abbreviations, IANA Considerations, author lists, and 
Requirement-—Level words. 


(vii) Typesets the documents in the standard RFC style. 


(viii) Verifies the correctness of published MIBs and ABNF 
fragments, using compilers. 


Providing authors with a review period of no less than 48 
hours to approve the document. 


Publishing new RFCs online by installing them in the official 

RFC archive, which is accessible via HTTP, FTP, and SMTP. The 
RFC Editor also provides compressed aggregate files of subsets 
of the complete RFC series, accessible via HTTP and FTP. PDF 

facsimiles are also maintained for all .txt RFCs. 


Publicly announcing the availability of new RFCs via a mailing 
list. 


Coordinating with the IANA for assignment of protocol 
parameter values for RFCs in the submission queue. 


Coordinating closely with the IESG to ensure that the rules of 
RFC 2026 (or replacement) are followed. RFC Editor personnel 
attend IETF meetings. A designated RFC Editor person serves 
as liaison to the IAB and IESG. 


(2) Individual Submission Publication 


The RFC Editor publishes technically competent and useful 
documents that arise outside the IETF process, in accordance with 
RFC 2026. The RFC Editor makes the final determination on the 
publishability of such documents, with review by the IESG and 
input from knowledgeable persons. 


The RFC Editor reviews all such documents for acceptable editorial 
quality and for content, and works with the authors when necessary 
to raise the quality to an acceptable level. 


(3) Online RFC meta-information 


The RFC editor publishes the following status information via the 
Web and FIP. 
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(a) A list of all RFCs currently published, including complete 
bibliographic information and document status. This list is 
published both in human and machine-readable (XML) forms. 


(b) A document consisting of summaries of RFCs in each range of 
100. 


(c) A list of errors found in published RFCs. 


(d) An "RFC Editor Queue" specifying the stage of every document 
in the process of editing, review, and publication. 


(e) An RFC Editor web site containing 


(i) A search engine for RFCs. 
(ii) Information on the RFC publication process. 
(iii) Links to the above published items. 


(4) Public Queries 


Responding to, and when appropriate, redirecting, a wide range of 
email queries received in the RFC Editor mailbox. 


II. Improved Process and Infrastructure 


When resources allow, the RFC Editor makes improvements to its 
processes and to the RFC repository infrastructure. This includes 
improvements and extensions to the set of scripts used by the RFC 
Editor: (i) to maintain its databases and web pages, and (ii) to 
increase the efficiency and quality of the editing process. 


Changes in procedure are often suggested by IETF members as well as 
by the IESG. Here are some examples of changes that are either in 
process or have been suggested for possible action in the future. 


(1) Publication process 


(a) Accepting documents in XML encoding when there is an 
accompanying tool that will produce nroff markup. 


(b) Studying the feasibility of editing the XML form of 
submitted documents, prior to producing the final nroff 
and .txt versions. 


(c) Adopting additional tools for verifying formal 


specification languages used in RFCs in addition to MIBs, 
PIBs, and ABNF. 
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(2) Database Accessibility and Quality 


(d) Improving the usefulness of the Errata information 


(i) Distinguish mere typographic errors from errors of 
substance 
(ii) Link errata to RFC index on web page. 


(e) Providing Web-based "enhanced" views of RFCs, including: 


(i) Links to other related RFCs and references. 
(ii) Links to and from online errata pages. 


(3) Maintaining an online repository of the corrected values of 
MIBs that have been published in RFCs. 


(4) Completing the RFC Online project, to bring online those early 
RFCs that are available only in paper form. 


Appendix D. Consultation with Foretec/CNRI: Secretariat and Meeting 
Planning 


Secretariat Responses to Questions from 
TAB Advisory Committee 


November 7, 2003 


(1) Your description of the function you are performing. Is that 
function, and its relationship to the IETF, adequately 
understood for working purposes, or is additional description 
required? If the latter, what would you suggest? 


+ +*+ * 


The Secretariat work is divided into four parts: Meeting Planning, WG 
support, IESG support, and IETF Community support. 


IETF meeting planning includes: identifying venues; negotiating 
contracts; working closely with the WG chairs and the IESG to 
schedule events and avoid conflicts; preparing the agendas for the WG 
sessions; arranging for F&B and AV; handling registration; seeking 
and signing up hosts; providing Internet access, a terminal room, and 
a wireless network when a host is not available; providing on-site 
support; and preparing the proceedings. Meeting planning also may 
include organizing the IESG retreat. 


WG support includes: maintaining and updating charters, milestones, 
and other information for the 140+ WGs; tracking changes in chairs; 
hosting and archiving the discussion mailing lists; and processing 
requests to publish IDs as RFCs. 
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IESG support includes: providing all support required for IESG 
teleconferences, which take place every two weeks and cover as many 
as 20+ documents each (i.e., processing "Last Calls", preparing the 
agenda and package, moderating the teleconference, preparing the 
minutes, sending out approval announcements, and updating the 
information in the ID Tracker); tracking the movement of I-Ds to 
RFCs; interfacing with the RFC Editor; performing administrative 
functions associated with WG creation, rechartering, and closing; 
maintaining the internal IESG Web pages; sending miscellaneous 
message to the IETF announcement list on behalf of the IESG, and 
posting them to the Web site, where applicable (e.g., appeals to the 
IESG and IESG responses to appeals); providing support to the NomCom, 
as needed (i.e., sending announcements, hosting/updating the Web 
site, arranging for conference calls); and developing Web-based tools 
to support IESG decision-making. 


IETF Community support includes: running the IETF meetings; hosting 
the IETF Web site, and keeping the web site it up to date; hosting 
the IETF announcement and discussion lists; responding to enquiries 
sent to the IETF Secretariat, the Executive Director, the meeting 
Registrar, the Webmaster, and the trouble-ticket systems; processing 
Intellectual Property Rights Notices; processing Liaison Statements; 
and posting I-Ds. 


(2) What staff is being used to perform these functions and 
what are their particular skills for doing so (either 
individually or in the aggregate) ? 


-- Three people perform administrative functions. 

-—- Four-and-a-half people perform technical support. 
-- One-and-a-half people do development. 

—- Three people do maintenance. 


(3) What criteria do you use to determine whether you are being 
successful, and how successful? Using those criteria, how 
successful are you and what could be done, especially from the 
IETF side, to improve that evaluation? 


+ + F i 


The continued efficient operation and evolution of the Internet is 
one important goal and challenge facing the IETF, and also the IETF 
Secretariat. Working together to assist the IETF in performing this 
important function has been a motivating factor in CNRI’s support for 
almost 15 years. The criteria followed by CNRI, and (more recently) 
its subsidiary Foretec, in their efforts on behalf of the entire 
Internet community is to provide a consistent and dependable 
mechanism that enables those persons interested in the many and 
varied issues that are raised within the IETF to perform their 
important work in the Internet standards process unburdened by the 
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routine administrative tasks associated with such endeavors. While I 
think this has been a successful activity over many years, there is 
always room for improvement; and a continuing dialogue between CNRI, 
ISOC, and the IETF leadership is useful for this purpose. High on my 
list of suggestions would be finding a way to increase the funds 
available to meet the increasing demands placed on the Secretariat. 
We can no longer depend only on attendance fees at meetings for this 
purpose. 


(4) How would you characterize the quality of your relationship 
with the IETF and its leadership? Is there mutual trust anda 
sense of working together on issues, or do you and your 


* 
* 
* 
* colleagues sometimes see the relationship as adversarial? 


While the Foretec management may have issues arising from day to day 
workflow demands on limited resources, CNRI values the trusted 
relationship we have had with the IETF community. The issue is 
cooperating in the development of new funding sources, and learning 
to live within the available resources. There is also an issue about 
effective lines of authority for the purpose of carrying out certain 
aspects of the overall standards process. There are many demands and 
pressures on the IESG and hence on the Secretariat. These workflow 
demands need to be addressed in a more systematic way for the benefit 
of all. 


* (5) Are there specific known problems you would like us to look 
* at and understand? If so, please describe them. 


Workload is high. Given the budgetary constraints that the 
Secretariat is under, there are no resources to take on additional 
work. The staff supporting all areas are working overtime just to 
keep up with the current workload. 


The Secretariat does not believe that the IETF Community appreciates 
the scope of the tasks. The Secretariat is automating more tasks, 
hopefully reducing the overall workload. There is a long queue of 
requests for new features in the tools that the Secretariat has 
built. There is not money to hire more developers. The IETF 
Executive Director is documenting processes. This has naturally 
caused discussion about whether the processes are what everyone wants 
the processes to be. While expected, it also increases workload. 


(6) How do you see the costs of your function evolving? If 
things become more costly over time, what are the main 
determiners of cost (e.g., general inflation, general IETF 


* 
* 
* 
* growth, increase in the number of particular functions you are 
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* carried out to perform,...). Are you doing some things that 
* IETF (IESG or otherwise) request that you do not consider 
* cost-effective and, if so, what are they? 


The total budget for IETF-related activities at Foretec last year was 
about $2.5M. The vast bulk was covered by IETF meeting fees, but the 
shortfall was covered by contributions from CNRI and Foretec. 


CNRI has been asked by its Board to find a solution to the problem. 


Appendix E. Consultation with ICANN: IANA protocol 
Parameter Assignment 


Responses to Questions from IAB Advisory Committee 
for the IANA Protocol Parameter Assignment Function 


November 7, 2003 


* (1) Your description of the function you are performing. Is that 
* function, and its relationship to the IETF, adequately described in 
* RFC 2860 (the MOU) and RFC 2434 (Guidelines for IANA 

* considerations), or is additional description required? If the 

* latter, what would you suggest? 


Per Michelle [Cotton, IANA], RFC 2860 probably remains sufficient as 
an MOU describing the functions that the IANA provides to the IETF. 
That office consists of, effective soon, a manager, three technical 
clerical staff (four full-time equivalents) plus half a dozen people 
on a consulting basis, performing functions for the IETF and the 
RIRs. The portion of that effort supporting IETF parameter 
assignment is roughly a full-time-equivalent plus software support 
and normal management/employment overheads. Fundamentally, the IETF 
parameter assignment function consists of accepting requests for 
protocol numbers for extensible protocols (such as IP Protocol, PPP 
PID, TCP/UDP Port, and the like), validating them according to 
business rules, identifying the appropriate registry, and in some 
cases portion of a registry, assigning the number, and documenting 
the result. 


RFC 2434 has served the IANA staff well as a guide, but is now in 
need of updating. Specific concerns with the document relate to the 
meaning of terms and the specificity of the information provided to 
the IANA in internet drafts. 


One issue relates to the meaning of the term "IETF consensus". When 


a document has passed through a defined consensus process, such as a 
working group, this is straightforward. When requests come to IANA 
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that have not done so, IANA needs specific guidance on IETF 
expectations. This generally comes in the form of AD direction or 
consulting advice. An improved process would help, though; business 
rules that inform the IANA when a new registry is appropriate, and 
what rules should be applied in assignment of values in any given 
registry, for example, would help. 


Parameter assignment being an essentially clerical function, specific 
guidance to the clerical staff is absolutely mandatory, and often 
lacking or unclear. In IANA’s dreams, every internet draft would 
contain an IANA Considerations section, even if all it said was "IANA 
need not concern itself with this draft". In the absence of such a 
statement, the IESG’s IANA Liaison is forced to read the entire 
document at least twice: once when the IESG is first handed the 
document, to ensure that any instructions to IANA are clear, and 
again when the IESG hands the document on, to ensure that it can 
perform the requests the draft makes. This is clearly time-consuming 
and prone to error. 


IANA is now receiving a certain level of instruction in internet 
drafts, which is good. However, even the present level of advice is 
frequently lacking in clarity. For example, a PPP NCP definition 
might well require the assignment of two PIDs, one for the data 
exchange and one for the NCP itself. These two numbers come from 
four very separate ranges: 0001..00FF, 0101..7FFF, 8001..BFFF, and 
C0O01..FFFF. The choice of range is important, especially on low 
speed lines using byte-oriented asynchronous transmission, as the 
data assignment has a trade-off implied for the relative frequency of 
messages using the specified protocol, and the control function PIDs 
are partitioned as well. In such a case, IANA needs to know not that 
"two PIDs are required", but that "two PPP PIDs are required, the 
data PID named <d-nameSgt; defined in section <> from the range 
0001..00FF, and the control PID named <c-nameSgt; defined in section 
<> from the range 8001..BFFE". 


Descriptions of registries to be designed need to be equally clear. 
If the specification says in its IANA Considerations section that "a 
registry named ’Fubar Code Points’ should be built; the initial 
values in a table <name> and IANA may assign additional values in any 
remaining value between the last initial code point and 65535", that 
is exactly what will happen. If there are additional expectations, 
such as "the working group’s assigned number advisor will be asked" 
or “all assignments must be made in an RFC of informational or 
standard status", they won’t necessarily be met - unless the IANA 
Considerations section specifies as much. What you put in the IANA 
Considerations section is what will be followed. It should be made 
clear so that the implementors get what they requested. Also, clear 
IANA Considerations sections also help the community, not only IANA. 


IAB Advisory Committee Informational [Page 36] 


RFC 3716 The IETF: Administration and Execution March 2004 


It makes (1) the authors think about all aspects of the creation of a 
registry and instructions on how to maintain but also (2) the public 

knows and understands the new registry instructions and how they can 

get assignments/registrations in that registry. 


Something that would materially help the IANA in its evaluation of 
internet drafts is a comment tracking system on the IETF side. The 
TANA’s use of such a system is apparent: any comments it makes on the 
draft would appear in the system, where the IESG may readily retrieve 
them, and the IANA can find its comments when the draft later comes 
there. To be truly helpful, it should also include at least any last 
call IETF commentary and AD commentary, including agreed changes to 
the document. This would permit IANA to review those notes as well, 
which may in turn elicit further IANA commentary ("if you make that 
change, you should also specify <> in the IANA Considerations 
section") or may guide IANA’s implementation. 


Normative references apply to IANA considerations as well as to other 
parts of the specification. Recently, the IESG started passing 
documents along prior to other documents normative for them, allowing 
them to sit in later queues to synchronize with their normative 
documents. In the special case where the normative document defines 
a registry and the draft under discussion assigns a value from that 
registry, this case needs to be handled in queue and in process like 
any other normative reference. 


* (2) What staff is being used to perform these functions and what 
* are their particular skills for doing so (either individually or 
* in the aggregate)? 


The staff assigned to this function, on 4 November 2003, includes 
Michelle Cotton and an assistant. They are essentially intelligent 
clerical staff familiar with computer back office applications, but 
otherwise with no special technical training. For technical 
questions, they depend heavily on advisors within IANA or assigned by 
the IETF. 


It should be kept in mind that it is not the IANA’s job to understand 
how every protocol works that is being defined in a new registry. 

The IANA needs to know how to create and maintain the registry 
administratively. 


* (3) What criteria do you use to determine whether you are being 

* successful, and how successful? Using those criteria, how 

* successful are you and what could be done, especially from the IETF 
* side, to improve that evaluation? 

The basic measure of success is the number of assignments made. 
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Michelle’s sense is that IANA is now moderately successful, however 
further improvement can be made internally and externally. 


Paul is defining web-based automation which should help various 
aspects of IANA’s work, including in part the IETF IANA function. 
Michelle believes that this automation will materially help her 
timeliness. But for that to be carried out properly, clear business 
guidelines must be given IANA for each of the existing registries, 
guidelines whose application can be readily automated. This is 
likely an IETF effort, or at least requires serious IETF input. 


(4) How would you characterize the quality of your relationship 
with the IETF and its leadership? Is there mutual trust anda 
sense of working together on issues, or do you and your 


* 
* 
* 
* colleagues sometimes see the relationship as adversarial? 


At this point, Michelle feels that IETF/IAB leadership is friendly 
and generally constructive. She is very cognizant of AD workload, 
and as such tries to focus questions and find other people to ask 
them of. As such, she perceives the communication level and volume 
to be on the light side of "about right". 


Again, amplified clarity of IESG/WG policy would reduce her question 
load, and there may be utility for an IAB liaison from the IANA such 
as IANA has with the IESG. That is really a question for the IAB; if 
it has questions for IANA, the chair should feel free to invite her 
comment or invite a liaison. 


* (5) Are there specific known problems you would like us to look at 
* and understand? If so, please describe them. 


This note has made a point concerning clarity of instructions, 
clarity of policy, and clarity of registries. There is ongoing work 
at IANA to clean up registry files inherited when IANA was split out 
from the RFC Editor’s office; in dealing with the business 
considerations questions already raised, it may be helpful fora 
tiger team from the IETF to review their registries with them and 
make suggestions. 


There is an ongoing problem with receiving announcements concerning 
at least some internet drafts. Michelle plans to follow up with the 
Secretariat on this, but in short it appears that the IANA liaison is 
not copied on at least some list that internet draft actions are 
announced on. This seems to pertain to individual submissions that 
the IESG advises the RFC Editor that it "has no problem" publishing. 


IAB Advisory Committee Informational [Page 38] 


RFC 3716 The IETF: Administration and Execution March 2004 


* (6) How do you see the costs of your function evolving? If things 
* become more costly over time, what are the main determiners of 

* cost (e.g., general inflation, general IETF growth, increase in the 
* number of particular functions you are carried out to 

* perform,...). Are you doing some things that IETF (IESG or 

* otherwise) request that you do not consider cost-effective and, 

* if so, what are they? 


As detailed, the function described in RFC 2860 represents 
approximately a person-equivalent, plus facilities, software support, 
and standard business loading. This has been the approximate load 
level for at least the past five years, and is projected to remain 
about the same for the near future. The cost-effectiveness issues 
revolve around human-in-the-loop effort involved in reading drafts, 
investigating inquiries, and such that have been detailed here. The 
sense is that an effective comment management system plus the work 
flow systems ICANN is planning to implement should result in a net 
near term improvement in efficiency and timeliness; projected IETF 
growth should then consume that improvement over time. 
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